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ABSTRACT 

We  are  interested  in  developing  programs  that  reason  about  digital  electronic  circuits,  in 
order  to  design,  redesign,  and  debug  them.  The  first  step  toward  developing  such 
programs  is  to  determine  a  useful  way  of  representing  the  design  and  operation  of  circuits. 
A  useful  representation  must  make  apparent  the  roles  of  various  circuit  components  in 
implementing  the  overall  circuit  function,  and  must  allow  a  program  to  reason  about  the 
operation  of  the  circuit  at  various  levels  of  abstraction.  This  paper  summarizes  our  efforts 
to  develop  such  a  representation.  This  work  is  closely  related  to  other  Al  work  on 
representing  plans  and  on  representing  and  reasoning  about  complex  physical  processes. 

1.  Introduction 

A  variety  of  issues  central  to  Al  arise  in  considering  the  problem  of  reasoning  about 
digital  electronic  circuits.  The  practical  significance  of  this  problem  is  becoming 
increasingly  clear  as  circuits  of  greater  and  greater  complexity  are  mass  produced  at  low 
cost  This  paper  considers  the  problem  of  representing  the  design  and  operation  of  digital 
circuits  in  a  way  that  is  useful  for  reasoning  about  their  operation,  design  revision, 
debugging,  testing,  and  maintenance. 

We  report  here  on  the  elements  of  such  a  representation  that  is  being  developed  as  part 
of  our  longer  term  research  toward  automating  the  functional  redesign  of  digital  electronic 
circuits.  By  functional  redesign  we  mean  the  task  of  altering  the  design  of  an  existing, 
well  understood  circuit,  in  order  to  meet  a  desired  change  to  its  functional  specifications. 
For  example,  consider  the  problem  of  redesigning  a  computer  terminal  in  order  to  alter  the 
number  of  characters  displayed  per  line  from  72  to  80,  to  alter  the  encoding  of  input 
characters  from  ASCII  to  EBCDIC,  or  to  make  the  character  font  programmable  rather  than 
fixed. 

In  order  to  reason  about  redesigning  an  existing  circuit  one  must  understand  the  basic 
operation  of  the  circuit,  as  well  as  the  relationship  between  the  original  design 
specifications  and  the  existing  circuit  Thus,  there  are  two  major  classes  of  representation 
problems  in  describing  the  design  and  operation  of  digital  circuits: 

Representing  the  basic  operation  of  the  circuit.  Representing  the  operation  of  a  circuit 
over  time  requires  describing  the  timing  and  synchronization  of  data-flow,  as  well  as  the 
function  and  interconnections  of  components.  Circuit  simulators,  such  as  those  typically 
reported  in  the  Design  Automation  literature  [2],  represent  circuit  operation  in  a  way  that 
supports  one  kind  of  reasoning  about  circuit  behavior;  i.e.,  answering  the  question  "What  is 
the  output  of  the  circuit  for  a  given  input?".  We  intend  our  representation  of  circuit 
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operation  to  be  useful  for  answering  additional  questions  such  as  "Will  two  given  signals 
always  be  high  at  the  same  time?",  or  "What  change  to  the  input  of  a  given  component  will 
cause  a  desired  change  to  its  output?".  We  have  developed  a  declarative  representation 
for  the  behavior  of  signals  over  time  and  the  synchronization  of  events,  along  with  a 
representation  of  functions  of  circuit  modules,  that  is  more  suited  to  answering  such 
questions.  Previous  work  in  Al  on  representing  and  reasoning  about  complex  processes 
includes,  for  examp le,  [5,  9,  1]. 

Representing  the  design  plan.  In  addition  to  representing  the  basic  operation  of  a 
circuit,  we  must  also  represent  the  relationship  between  the  design  specification  and  the 
implemented  circuit,  in  a  way  that  allows  answering  questions  such  as  "What  is  the  rote  of 
a  given  circuit  component  in  implementing  the  overall  design  specifications?”,  and  "How  is  a 
desired  function  decomposed  into  sub  functions,  and  implemented  by  a  variety  of  circuit 
modules?".  We  represent  the  relationship  between  the  design  specifications  and  the 
implemented  circuit  in  terms  of  a  hierarchical  plan  for  the  design  of  the  circuit  This  plan 
consists  of  several  representations  of  portions  of  the  circuit  at  different  levels  of 
abstraction,  along  with  various  kinds  of  links  between  the  levels.  Relevant  work  on 
representing  hierarchical  plans  in  domains  other  than  electronics  includes  [8,  6.  4]. 

2.  Overview  of  the  Representation 

Our  circuit  representation  involves  describing  a  given  circuit  at  several  levels  of 
abstraction,  ranging  from  a  very  high  level  functional  descriptions  down  to  its  realization  in 
TTL  level  components  (e.g.  flip  flops,  logic  gates,  etc.).  A  uniform  representation  scheme  is 
used  for  any  such  level  of  description  The  relationship  between  different  levels  of 
description  is  characterized  in  terms  of  general  rules  of  circuit  design.  The  following 
sections  highlight  the  major  notions  underlying  our  representation. 

2.1.  Representing  the  Structure  and  Operation  of  the  Circuit 

The  circuit  is  described  in  terms  of  four  entities:  (1)  circuit  modules,  (2)  their  associated 
functions,  (3)  data- paths  between  modules  (e.g.,  wires  or  busses),  and  (4)  data-streams  (the 
sequence  of  voltages  or  higher  level  data  flowing  on  a  particular  data-path).  Each 
abstraction  of  the  circuit  corresponds  to  a  collection  of  these  four  entities.  A  number  of 
modules  can  be  grouped  together  and  viewed  as  a  single  module.  Similarly,  a  number  of 
data-paths  can  be  grouped  together  and  viewed  as  a  single  data-path.  An  abstraction  of  a 
function  corresponds  to  a  partial  definition  of  that  function.  Data-streams  of  one  type 
(e.g..  a  stream  of  bits)  can  be  viewed  as  representing  data-streams  of  another  type  (e.g.,  a 
stream  of  characters). 
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Our  representation  of  the  flow  of  data  within  the  circuit  is  based  on  a  declarative 
characterization  of  the  sequence  of  data  on  a  given  data-path.  For  instance,  we  can 
explicitly  represent  the  statement  that,  on  some  data  path  0,  a  new  ASCII  character  appears 
every  10  milliseconds,  synchronized  with  clock  C.  This  allows  answering  such  questions  as, 
"Why  is  latch  LI  clocked  by  clock  C ?"  or,  "What  is  the  minimum  setup  time  ROM  R1  will 
ever  have  to  handle?" 

Since  module  functions  relate  input  data-streams  to  output  data-streams,  their 
representation  is  closely  tied  to  the  data  representation.  In  particular,  function  descriptions 
specify  the  times  at  which  elements  in  the  output  data-stream  begin,  along  with  their  data 
value  and  their  time  duration  These  are  given  as  a  function  of  the  value,  start  time,  and 
duration  of  elements  in  the  input  data-streams.  Function  descriptions  can  often  be 
simplified  greatly  once  the  structure  of  input  data-streams  is  known  (e.g.  once  it  is  known 
that  a  particular  input  is  a  periodic  sequence  of  characters).  A  module  is  actually  described 
by  two  functions,  one  which  describes  the  module's  actual  behavior  and  one  which 
describes  what  the  module  must  do  for  the  circuit  to  work.  Usually,  the  former  will  be  a 
more  detailed  version  of  the  latter. 

2.2.  Representing  the  Design  Plan 

The  designed  circuit  is  represented  in  terms  of  a  hierarchical  plan  for  implementing  the 
design  specifications.  We  do  not  require  that  this  design  plan  reflect  the  process  by 
which  the  design  was  actually  created,  only  that  the  plan  explain  the  design  as  it  exists. 
The  topmost  level  of  the  hierarchy  corresponds  to  a  high  level  specification  for  the  design; 
the  bottom  most  level  corresponds  to  the  implemented  circuit  Each  intermediate  node  in 
the  hierarchy  corresponds  to  an  abstraction  of  some  portion  of  the  circuit  structure  and 
function  that  represents  some  set  of  commitments  about  the  circuit  implementation  Each 
such  abstraction  is  consistent  with  the  desired  functions!  specifications  of  its  ancestor,  and 
may  itself  contain  abstract  circuit  modules  whose  implementation  is  not  yet  specified 

Successive  abstractions  in  the  hierarchy  are  tied  together  by  rules  that  characterize 

circuit-independent  knowledge  about  implementing  modules  and  about  encoding  data  For 

example,  one  such  rule  states  that  in  order  to  convert  a  parallel  bit-string  into  a  serial  bit¬ 

string.  one  can  use  a  shift  register  in  a  specified  configuration.  Each  rule  application 
represents  some  commitment  regarding  the  circuit  implementation,  and  leads  to  a  less 
abstract  circuit  description.  For  any  component,  it  should  be  possible  to  trace  back 
through  the  rules  that  lead  to  it.  in  order  to  characterize  that  component's  role  in 

implementing  the  specifications. 


3.  Currant  Status 

We  are  currently  debugging  our  representation  by  using  it  to  describe  portions  of  the 
video  display  controller  for  a  computer  terminal.  Our .  representation  system  is  embedded 
within  UNITs  [7],  a  general-purpose  frame-based  representation  system.  A  detailed 
description  of  our  representation,  and  its  use  to  describe  a  specific  circuit  is  available  in 
[33.  We  also  suggest  there  how  this  representation  could  be  used  in  support  of  a 
system  for  automated  functional  redesign 

4.  Acknowledgments 

Other  members  of  the  Digital  Design  Project  include  Saul  Amarel.  Giles  Lafue,  Saul  Levy. 
Jeff  Shulman,  and  Tim  Weinrich.  John  Grason  and  Larry  O'Neill  have  provided  valuable 
suggestions  and  criticisms. 


5 


References 


[1]  J.  S.  Brown  and  R.  Burton. 

Multiple  Representations  Of  Knowledge  For  Tutorial  Reasoning. 

In  Representation  And  Understanding:  Studies  in  Cognitive  Science,  .  Academic 
Press,  1975. 

[2]  IEEE,  Minneapolis,  Minnesota 

17th  Design  Automation  Conference  Proceedings,  1980. 

[3]  T.  M  Mitchell,  L  Steinberg,  R.  G  Smith,  P.  Schooley,  H.  Jacobs,  V.  Kelly. 
Representations  For  Reasoning  About  Digital  Designs. 

Forthcoming 

[4]  C.  Rich  and  K  Shrobe. 

Initial  Report  On  A  LISP  Programmer's  Apprentice. 

Technical  Report  TR-354,  MIT,  1976. 

[5]  C.  Rieger  and  M.  Grinberg. 

A  System  Of  Cause-Effect  Representation  And  Simulation  For  Computer-Aided 
Desiga 

In  J.  C.  Latombe  (editor).  Artificial  Intelligence  And  Pattern  Recognition  In 

Computer  Aided  Design,  pages  299-326.  North-Holland  Publishing  Company, 
1978. 

[6]  E  Sacerdoti. 

A  Structure  For  Plans  And  Behavior. 

Elsevier  North-Holland,  1977. 

[7]  R.  G  Smith  and  P.  Friedland 

Unit  Package  User's  Guide. 

Technical  Memorandum  80/L,  Defence  Research  Establishment  Atlantic,  Dec,  1980. 
Also  Stanford  Heuristic  Programming  Project  Memo  HPP-80-28. 

[8]  M  J.  Stefik. 

Planning  With  Constraints. 

PhD  thesis,  Stanford  University,  1980. 

Also  available  as  a  Computer  Science  Dept  technical  report,  number  STAN-CS-80- 
784. 

[9]  G  J.  Sussman. 

At  The  Boundary  Between  Analysis  And  Synthesis. 

In  J.  C.  Latombe  (editor).  Artificial  Intelligence  And  Pattern  Recognition  In 

Computer  Aided  Design,  pages  261-290.  North-Holland  Publishing  Company, 
1978. 


